Organizations oftentimes use applications running on legacy systems, such as mainframes that have been in place for a long time and serve for driving mission-critical computations. In order to integrate such legacy mainframes into modern computing environments, it is known to employ so-called mainframe integration products. The task of mainframe integration, however, is very complex, resource-intensive and time-consuming due to the fundamental technical differences between the legacy mainframe world and modern computing environments, as e.g. outlined in “A Better Path Toward Legacy Integration with the Cloud” (cf. http://cloudcomputing.sys-con.com/node/1880221).
Generally, mainframe integration products are designed to route communications between clients and the mainframe. To this end, they typically communicate with client web browsers and/or web service consumers using modern protocols (e.g. HTTP/S and/or SOAP) on the one hand and communicate on the other hand with the legacy mainframe using mainframe protocols, such as telnet connections over a TCP/IP socket or even SNA connections in very old systems. In this context, mainframe integration products have to establish a persistent TCP/IP connection with the mainframe. Examples of known mainframe integration products are e.g. disclosed in U.S. Pat. No. 7,877,783 B1, U.S. Pat. No. 7,877,794 B2 and U.S. Pat. No. 7,562,146 B2.
Moreover, the communication between a client and a mainframe is generally screen-based, in that the requesting entity (the client) is served with display screens of the legacy mainframe one after another and may navigate between these screens. Therefore, a given communication typically comprises a plurality of request/response cycles between the client and the mainframe, i.e. each cycle is always part of a larger “session”, in that the current request/response cycle depends upon the preceding screens through which the user has navigated beforehand.
Examples of mainframe hardware and their corresponding operating systems are IBM AS/400, z/OS, VSE, MVS, BS2000, Tandem, which typically communicate with mainframe integration products over Telnet-based protocols, such as TN3270, TN5250, BS2000 and Tandem protocols.
Furthermore, in a different area of computing apart from mainframe integration, “cloud computing” becomes more and more popular. “Cloud computing” refers to the concept of moving certain parts of an application's processing tasks to a third-party environment located outside of the application's network, in particular on the Internet. The third-party cloud computing environment hosts the deployed application on one or multiple servers, which makes it possible to benefit from the vastly increased processing capabilities offered thereby, as compared to traditional “local processing”. Various commercial cloud-computing environments are already in place, e.g. Amazon EC2 or Google Apps, which allow deploying web services to the Internet, which are then executed on the cloud computing provider's servers. As the skilled person will readily observe, Internet communications and web services generally rely on the concept of “loosely coupled” entities, in which a given request/response cycle is independent of any preceding communication cycles.
In view of the above, deploying a mainframe integration product “to the cloud” is very difficult. Firstly, organizations will hardly agree to expose their mainframe telnet access to a third-party cloud computing environment located on the Internet due to security concerns. Secondly, having to adhere to the above-described stateless request/response scheme employed in Internet communications makes it very difficult to deploy a mainframe integration product to a cloud computing environment due to the stateful screen-based nature of mainframe applications.
It is therefore the technical problem underlying the present technology to provide an approach for cloud-based mainframe integration that at least partly overcomes the above explained disadvantages of the prior art.
This problem is according to one aspect of the technology solved by a cloud-based mainframe integration system for providing at least one client access to at least one mainframe, the at least one mainframe being accessible over a persistent communication connection. In the embodiment of claim 1, the cloud-based mainframe integration system comprises:    a. at least one mainframe integration server (MIS), adapted for routing communications between the at least one client and the at least one mainframe;    b. wherein the at least one MIS is located within a cloud computing environment separate from a computer network in which the at least one mainframe is located; and    c. wherein the at least one MIS is adapted for communicating with the separate network over a non-persistent communication connection.
Accordingly, the embodiment defines a mainframe integration system, whose mainframe integration server (MIS) executes inside a cloud computing environment (preferably operated by a third-party) and thus outside of the (corporate) computer network in which the mainframe resides. Advantageously, the MIS communicates with the separate network over a non-persistent communication connection (typically the Internet) and preferably uses standard Internet protocols such as HTTP/S. As a result, the persistent communication connection required by the mainframe can be safely kept inside the mainframe's network, thereby avoiding the mainframe's security-critical telnet access to be revealed on the insecure Internet. This approach hence differs from traditional mainframe integration products, which are always located within the same network as the mainframe itself (due to the required persistent connection and/or security requirements).
In a preferred implementation of the above-described system, the non-persistent communication connection between the cloud computing environment and the mainframe's network is used for tunneling the mainframe protocol communication (e.g. telnet) over standard Internet protocols such as HTTP/S. In this context, the person skilled in the art will appreciate that HTTP gateways for telnet connections are already known (cf. e.g. http://www.mosha.net/01-telnet-gateway/telnet.shtml). However, such known HTTP-telnet-gateways still require revealing the telnet access credentials over the internet and thus cannot be employed in the present context due to security reasons. In addition, they do not support maintaining and/or replicating the session state between multiple MIS nodes, they do not allow for increasing and decreasing the number of MIS instances elastically based on the application load and they do not support encapsulating multiple MIS instances behind a single load balancer entry point.
In summary, the above-described system allows the security-relevant telnet access to be safely kept inside the corporate network containing the mainframe, while the “intelligent part” of the mainframe integration product (the MIS) can be deployed “to the cloud” (i.e. to the cloud computing environment), thereby being able to benefit from the advantages of a cloud computing environment, such as increased processing power, scalability and fail-safety.
In another aspect of the present technology, the cloud-based mainframe integration system further comprises at least one mainframe communication bridge (MCB) located within the network of the at least one mainframe, the at least one MCB being adapted for maintaining a persistent communication connection with the at least one mainframe and further adapted for communicating with the cloud computing environment over the non-persistent communication connection. Accordingly, the mainframe integration application is actually divided into two separate components, namely at least one mainframe integration server (MIS) and at least one mainframe communication bridge (MCB). The MIS is located within a cloud computing environment preferably provided by a third-party, whereas the MCB resides within a separate computer network, more precisely that local network in which also the mainframe is located. The MCB maintains a required persistent connection with the mainframe (e.g. over a persistent TCP/IP socket). The communication between the MCB and the MIS is, on the contrary, performed over a non-persistent connection, preferably using internet protocols such as HTTP, HTTPS and/or SOAP.
In yet another aspect, the at least one MIS may be adapted for storing a session state relating to a request/response cycle of the communication between the at least one client and the at least one mainframe, the session state being usable for subsequent request/response cycles between the at least one client and the at least one mainframe. As explained above, mainframe communications are generally session-based, in that a given communication normally comprises a sequence of multiple request/response cycles between the client and the mainframe. Accordingly, the MIS stores a session state, which may be used in a current request/response cycle to correlate this cycle with a preceding cycle.
Preferably, the at least one MIS is adapted for sending the session state to the at least one MCB for being stored at the at least one MCB. Accordingly, the current session state is advantageously replicated to the MCB, which therefore serves as a backup. This aspect allows a given MIS to stop executing at any arbitrary point in time without interrupting a given client/mainframe communication, since the current session state may be easily restored from the MCB. This aspect is particularly advantageous in the context of cloud computing, since new server instances are frequently started (spawned) and old server instances are frequently “killed” in cloud computing environments.
Additionally or alternatively, the cloud-based mainframe integration system further comprises a load balancer, wherein the load balancer is adapted for dispatching a communication coming from the network of the at least one mainframe to one of a plurality of MIS inside the cloud computing environment. Accordingly, each request entering the cloud computing environment is dispatched to any of a plurality of given MIS instances (in accordance with the load balancer's scheduling policy). This aspect has the advantageous effect that the processing load of multiple client/mainframe communications can be optimally balanced between all available MIS instances, thereby allowing an optimal resource usage.
In this context, the MIS selected by the load balancer is preferably adapted for obtaining a current session state relating to the communication from another MIS, if the selected MIS does not possess the current session state. Accordingly, any newly started (spawned) MIS instance—which does not possess the session state required to handle a given client/mainframe communication—can still handle this communication by obtaining the session state from another MIS instance. As a result, the flexibility of the present system is improved to a great extent, since new MIS instances can be dynamically added to the cloud computing environment and take over the processing of already existing client/mainframe communications.
In yet another aspect, the MIS selected by the load balancer is adapted for obtaining a current session state relating to the communication from the at least one MCB, if none of the other MIS possesses the current session state. Accordingly, even if all MIS instances possessing the current session information are no longer available, the communication can still be handled based on the session state backup stored at the MCB. This aspect allows the cloud provider for removing any given MIS instance without the need to check whether it is the last instance to hold a given session state.
Furthermore, the at least one MIS may be adapted for sending a connection identifier to the at least one client, the connection identifier identifying the MCB which handled the communication between the at least one client and the at least one mainframe. Accordingly, after having handled a given request/response cycle, the MIS may provide the client with a “cookie” storing the ID of the MCB that was involved in the cycle. As a result, the at least one MIS may be adapted for receiving a client request comprising the connection identifier and further adapted for determining whether it already established a connection to the at least one MCB identified by the connection identifier, and if not, redirecting the client request back to the load balancer. Accordingly, if a MIS contacted by a client, through the load balancer, has not yet handled a prior conversation with the desired MCB, the MIS may redirect the client request to the load balancer, so that the load balancer may select another MIS (which hopefully already possesses the connection to the desired MCB). To this end, the at least one MIS may add its own identifier to the client request when redirecting the client request to the load balancer, so that the load balancer does not dispatch the request again to the MIS from which the request was redirected.
Preferably, the at least one MCB can communicate with the at least one MIS only via the load balancer, and wherein the at least one MCB is adapted for sending a plurality of registration requests to the load balancer in order to register with substantially all MIS instances. Accordingly, since a given MCB cannot tell for sure how many MIS are currently running inside the cloud computing environment (behind the load balancer), the MCB preferably executes a registration loop in which it intends to register with most of the MIS, as will be further explained in the detailed description below.
The present technology further concerns a method for providing at least one client access to at least one mainframe, the at least one mainframe being accessible over a persistent communication connection, the method comprising the steps of routing, by at least one mainframe integration server (MIS), communications between the at least one client and the at least one mainframe, wherein the at least one MIS is located within a cloud computing environment separate from a computer network in which the at least one mainframe is located, and wherein the at least one MIS is adapted for communicating with the separate network over a non-persistent communication connection. Further advantageous modifications of embodiments of the method of the technology are defined in further dependent claims, wherein the present method may generally perform any of the functionalities described above in connection with the cloud-based mainframe integration system. Moreover, a computer program is provided comprising instructions for implementing any of the above methods.